This document (originally a bug report to Metrowerks) explains the inconsistent way that THINK C, MPW C, and CodeWarrior C handle the new line and carriage return characters. This issue is very important to anyone writing a code resource that will be compiled by one compiler but may be called by code from another compiler.
From: Denis Pelli (10/3/1994)
To: Berardino E. Baratta
Dear Berardino
Before you produce the final version of the ANSI library [for Metrowerks CodeWarrior C 5] I hope you'll read a note I wrote explaining the deeper problem about handling \r and \n in stdio on Macintosh. I submitted this to metrowerks support a while back, when they issued the bug number about \r [Bug T509]. I also sent a copy to PJ Plauger (plauger!pjp@uunet.uu.net), author of the Standard C book and your Standard C library. He replied (8/2/94) by adding a few thoughtful comments to my explanation. So I'm pasting in below that version, [including his comments in brackets]. And, at the end, I've also added a helpful comment from Johan Strandberg, which quotes the relevant part of the standard. We're all in agreement that there's a problem that should be fixed. There are two possible solutions, MPW's and THINK's. Either solution would be ok in my view. However, people producing code resources in CodeWarrior that must work with existing applications in MPW or THINK C will want a compatible solution. The most elegant solution, making everybody happy, would be a compile-time switch, choosing between the MPW and THINK solutions.
regards
denis
p.s. THINK's solution is clearly in conformance with the standard. PJ Plauger and Johan Strandberg take opposite positions on whether MPW's solution is in accordance with the C Standard. I'm not sufficiently expert to disagree with either of them, but I do know that in real life many of your customers will want to write code resources that are compatible with existing MPW C applications, even if that means violating some rules.
BUG DESCRIPTION
Bug severity: Operations executed incorrectly
Reproducibility: Always
Problem summary:
The Metrowerks stdio library translates \n to \r--but not vice versa--on text stream output. (I didn't check input.) This is very bad, as it loses information. Merely reading and writing a text file will irretrievably convert all the linefeeds and returns to returns. [P.J. Plauger adds, "In principle, this is a conforming solution, since Macintosh has precluded a legitimate way to represent '\r' in a text file. In practice, it might be more politic to provide a solution, as described below."]
The underlying problem is that Standard C specifies that linefeeds in character constants and strings in C source files should be represented as \n (which is 10 according to ascii), yet Apple, in their wisdom, long ago chose to separate lines in Macintosh files with character code 13, which ascii calls the return character \r. This problem cannot be ignored, as users demand normal Macintosh text files as well as Standard C source code. The problem is resolved differently by the Apple MPW and Symantec THINK C compilers, but is not well resolved by the CodeWarrior C compiler. [Still true for version CW 4.5.]
To solve the problem, MPW brazenly ignores the ascii convention and interprets '\n' in source files as 13, and '\r' as 10. [P.J. Plauger adds, "This is not in conformance with the C Standard."] THINK C, more subtly, exchanges character codes 10 and 13 in text i/o streams (binary i/o streams are left unmodified). [P.J. Plauger adds, "This approach conforms to the C Standard and has the advantage of offering *some* way of representing '\r' in text files. The drawback is that not all programs that produce text files necessarily cooperate in the conspiracy."] Metrowerks should implement one of these two solutions. Each solution works perfectly within the respective environment. In theory, I think the THINK C solution is more elegant, but practical considerations of compatibility lead me to recommend that Metrowerks adopt the MPW solution.
The difficulty is code resources. A colleague and I have struggled to make THINK C code resources to use with MATLAB, which uses the MPW stdio library. The two schemes (redefinition and translation) do not easily coexist. Note that THINK C resolves the problem in its stdio library, whereas MPW C resolves the problem in how it compiles the user's code. When you compile THINK C code resources that call the MPW stdio library both solutions are bypassed and the old problem rears its ugly head. The \n and \r characters in the THINK C code have their conventional definitions (because they're compiled by THINK C) and are passed untranslated (because they're processed by the MPW stdio library). Since many of the stdio functions are line oriented, and lines are terminated by 10 in THINK C and 13 in MPW C, it is very difficult to achieve reasonable console i/o.
Many users of the Metrowerks CodeWarrior, like us, will want to create code resources that will have to coexist with the MPW stdio library. The only way of achieving true compatibility is to adopt MPW's scheme for resolving the conflict between Standard C and Macintosh text file conventions. Please define '\n' as 13 and '\r' as 10.
(A more ambitious solution would make this a compile-time choice, allowing applications to use the more elegant THINK-compatible runtime stdio translation of text streams, and allowing code resources to use the MPW-compatible modification of the ascii convention. It wouldn't require two versions of the stdio library, just a global that specified whether the stdio library should enable translation.)
As always in Standard C, printf("\n") should move the cursor to the left margin and down one line. printf("\r") should just move it to the left margin.
[P.J. Plauger adds, "However it is fixed, the problem lies in lower-level functions supplied by Metrowerks. The portable part of the Standard C library should be unaffected by the solution."]
Metrowerks CodeWarrior is a wonderful product. Thanks. [P.J. Plauger adds, "Glad to hear it."]
Denis Pelli
Professor of Neuroscience
Syracuse University
***************************************
From: Johan Strandberg (8/3/94)
To: Denis Pelli, owner-cwarrior@netcom.com
Mail*Link® SMTP RE>\n vs \r
Denis Pelli writes:
>The underlying problem is that Standard C specifies that linefeeds in
>character constants and strings in C source files should be represented as \n
>(which is 10 according to ascii)
>[...]
>To solve the problem, MPW brazenly ignores the ascii convention and
>interprets '\n' in source files as 13, and '\r' as 10.
>[...]
If life was that simple....
-------------------
X3.159-1989 2.2.2:
[...]
\n (new line) Moves the active position to the initial position
of the next line.
\r (carriage return) Moves the active position to the initial
position of the current line.
[...]
Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file need not be identical to the internal representations, and are outside the scope of this standard.
-------------------
As you can see, there is nothing stating what ASCII codeing should be generated internaly by '\n'. ONLY THAT IT CAUSES A NEW LINE! MPW solves it by defining the IMPLEMENTATION-DEFINED value of '\n' to be 13, and THINK by changing the mapping between internal and external representations.
Both these solutions are correct according to the standard. Too bad they are not compatible. [sigh]
